1. Field of the Disclosure
The present disclosure generally relates to a proximity map request method, a server and a network entity using the same method, a proximity request validating method, and a server and a network entity using the same method.
2. Description of Related Art
In the field of D2D communication which is often referred to as a Proximity-based Services (ProSe) communication, a UE typically may directly discover another UE and subsequently performs D2D communication with another UE with or without the assistance of a core network such as an Evolved Packet Core (EPC). In a proximity discovery procedure, a ProSe-enabled UE may transmit a proximity request for discovering another ProSe-enabled UE are described in 3GPP TS 23.303 which are incorporated by reference herein. When the proximity discovery procedure occurs in the EPC-level, the proximity discovery procedure would involve a proximity request validation procedure by which a network entity such as a ProSe function in the EPC network would ask the a targeted UE to confirm a permission for the proximity request if a profile of the targeted UE indicates that the proximity request need to be explicitly validated described in 3GPP TS 24.334 which are incorporated by reference herein. The ProSe Function is the logical function that is used for network related actions required for ProSe. The ProSe Function plays different roles for each of the features of ProSe.
A proximity discovery procedure may involve different types of identifiers (ID). A network level user ID such as an EPC ProSe user ID (EPUID) is an identifier for EPC-level ProSe discovery and EPC support of WLAN direct communication to uniquely identify a UE registered for ProSe. This identifier could occasionally be reassigned by the ProSe Function in an EPC network. An application Layer User ID (ALUID) is an identifier that identifies a user within the context of specific application.
FIG. 1 shows a general call flow of an EPC-level ProSe discovery procedure which is consistent with 3GPP TS 23.303 for example. In step S110 and S120, in order to obtain ProSe service, UE A and UE B would perform UE registration for ProSe or D2D communication with the ProSe Function A and ProSe Function B residing in their respective home public land mobile networks (Home PLMNs), respectively. In step S130 and S140, in order to check an authorization of the requested application in the ProSe function (such as the ProSe Function A and the ProSe Function B) and request the APP server to register UE's ALUID with an EPUID, UE A and UE B would perform application registration for ProSe with the ProSe Function A and the ProSe Function B residing in their respective Home PLMNs, respectively. In step S150, UE A would make a proximity request (to possibly indicate a window of time during which the proximity request is valid) for UE B. For example, UE A might be alerted for proximity with UE B. In response to the proximity request, ProSe Function A would request for a location update for UE A and for UE B. The location updates could be periodic or could be based on a triggered event or both. In order to request location updates for UE A, ProSe Function A would contact the SUPL Location Platform (SLP) A. Similarly, in order to request a location update for UE B, ProSe Function A would contact ProSe Function B, which would request a location update for UE B from SLP B.
In step S160 and S170, the locations of UE A and UE B could be reported to their respective ProSe Functions intermittently. ProSe Function B may forward the updates of the locations of UE B to ProSe Function A based on conditions set by ProSe Function A. Whenever ProSe Function A receives the updates of the locations of UE A and/or UE B, Prose Function A may perform proximity analysis for the locations of UE A and UE B. In step S180, when ProSe Function A detects that UE A and UE B are in proximity, ProSe Function A would inform UE A that UE B is in proximity and may optionally provide UE A with an assistance information for WLAN direct discovery and communication with UE B. Similarly, ProSe Function A would inform ProSe Function B, which in turn would inform UE B of the detected proximity of UE A. The Prose Function B may also optionally provide UE B with the assistance information for WLAN direct discovery and communication with UE A.
FIG. 2 is a flow chart which illustrates an example of an EPC-level proximity request procedure. In step S210, UE A sends a Proximity Request message to ProSe Function A. In response to receiving the Proximity Request message, in step S220, ProSe Function A would perform a proximity map request procedure with the APP server. The Proximity map request procedure is used for requesting the EPUID of UE B for which UE A shall get alerts when in proximity of UE B, and the identity of the ProSe Function (PFID) for UE B as well. The APP server would have compatibility of storing of EPUIDs and ProSe Function IDs (PFIDs) and mapping of ALUIDs and EPUIDs. In step S230, ProSe Function A propagates the Proximity Request message with EPUID of UE B to ProSe Function B. Based on EPUID_B received in the step S230, ProSe Function B retrieves UE B's record such as UE B's last known location and may reject the request be sending a Proximity Request Reject message towards UE A with an appropriate cause value (S240). In step S250, the proximity request validation procedure would be performed depending on UE B's ProSe profile, UE B may be asked to confirm permission for the proximity request. In step S260, ProSe Function B requests location reporting on UE B from SLP B and acknowledges the proximity request to ProSe Function A and provides UE B's current location (if known). In step S280, ProSe Function A requests location reporting on UE A from SLP A. If UE A's current location is available and if UE B's location was included in step S260, ProSe Function A may decide to cancel the Proximity Request procedure if it determines that the UEs are unlikely to enter proximity within the requested time window. Otherwise, ProSe Function A acknowledges the proximity request to UE A (S290). Examples of the proximity request procedure are described in 3GPP TS 23.303 and TS 24.334 which are incorporated by reference herein, and the detailed descriptions would be described later.
It should be noticed that, in response to receiving a proximity map request message, the APP server would check a user of the UE B's application-specific ProSe permissions, and confirms that a user of the UE A is allowed to discover the user of the UE B. However, the privacy setting in the APP server is only accepting or rejecting the proximity request, which is not enough for an application such as a social network application and lack of privacy.